- Upgrade to Microsoft Office Pro and Windows 11 Pro with this bundle for 87% off
- Get 3 months of Xbox Game Pass Ultimate for 28% off
- Buy a Microsoft Project Pro or Microsoft Visio Pro license for just $18 with this deal
- How I optimized the cheapest 98-inch TV available to look and sound incredible (and it's $1,000 off)
- The best blood pressure watches of 2024
Is tackling technical debt key to modernizing federal networks?
I often get brought into meetings when a customer starts talking “DevOps”. We’ll discuss everything from infrastructure-as-code, automation, and continuous integration, to network as a service (NaaS), cloud, and all things modernization. Regardless of what we cover, the customer “wants” always tend to be consistent; predictable pricing, minimal risk, and (most importantly) to move faster. Once the meeting is over, I usually get the same question. “So, what do I need to buy?”
Putting technical debt to work
This is when the hard conversation actually starts. It’s not necessarily from the customers perspective, but from our Cisco account team’s perspective. The answer to their question is “technically, nothing.” But after fifteen seconds of awkward silence, someone will respond with “what do you mean?” and justifiably so.
Here’s why I answer with that . . . we can “software-define” and “as a service” just about anything. We’re dedicated to our customers and we will figure out how to get the right gear from our factory to your warehouse as fast as you need it. Unfortunately, none of that really matters if you don’t transform the way you operate the network. Of course, deployment is a key part of the process but truly transforming operations tends to be the much bigger challenge.
Let’s put this in context of eliminating technical debt. Say we have a hypothetical government agency that has 30,000 devices going end-of-support in six months. This puts them at-risk. No support means no software patches — which means security gaps.
Unfortunately, their existing processes put them at eighteen months to refresh all 30,000 devices (not including procurement, award, lead times, etc). Now they’re looking at closer to twenty months, which means well over a year that their agency is operating at-risk. This gets people’s attention, often resulting in an all hands-on deck approach accompanied by a big check, replacing like-for-like while leveraging automation to deploy. Assuming everything goes off without a hitch, they’ll get everything deployed. But even if they meet the six month at-risk window, what happens during the next end-of-support announcement?
Steps to transform your technical debt
You can keep kicking that can down the road but can you ever break the cycle? I believe you can and suggest the following steps to transform your operations before the risks appears:
- First, remember it’s all about the data. Whether it’s from your infrastructure, platforms, products, or software, pretty much anything with a CPU runs on data. Sure, some have nice user interfaces, and others require heavy customization, but ultimately you are sending operating instructions in the form of data and pushing across a variety of software and devices. This is why you must get control of your data by transforming your operations. Start by extracting all of it from your infrastructure and centralizing it (creating your “source-of-truth”). Thankfully this can be automated, even in complex multi-vendor, or legacy environments.
- Second, make your data easier to manage. Structure and simplify it. By structure, I mean organizing data in industry-standard formats like JSON or YANG. Once you dig into network data models, you’ll notice a lot of redundancy. Strip out the unique variables — IP addresses, hostnames, descriptions — and what remains? Almost identical data models. So why do you need so many duplicates? You don’t. This is what I mean by simplifying. Pull the variables or key-values out of your data models and put them in a separate data source. A good example would be an IPAM like InfoBlox, Netbox, or Nautobot. With the key-values stored somewhere else, this leaves you with versatile data models for network services that are reusable across devices, cutting down the volume of data to manage, which leads to the next step.
- Third, manage your data. This is the fun part. Where your keep your data is entirely up to you, but I highly recommend putting everything in a source control manager. Software developers have been using these tools for years. The immediate value you get through implementing version control justifies all the work. Everything else is just an added benefit. This is also where you start to see the operational transformation. When you manage the source-of-truth (SoT) data and not the individual device, you will always have an accurate depiction of your network because the network is always in sync with the SoT. When the SoT is accurate, you can start to wrap policy and governance around it, which is how we start to minimize risk. This leads to the final step.
- Lastly, control your data. You’ve probably heard of continuous integration and continuous deployment (CI/CD). If you haven’t, here is a quick explanation. Continuous integration allows you to always be validating, testing, measuring, and getting feedback of proposed changes without those changes being implemented in production. Now that we are managing our infrastructure as data, we can use CI to ensure any change that goes into production will be compliant and will not have any negative impact to the users. How is this possible? By using a digital twin. Remember, our data is not necessarily dependent on any hardware. All we need are virtual versions of our infrastructure and we can get close to a decent replica of our production environment, at least as far as our automated tests are concerned. Even if our digital twin isn’t exactly like our production environment, using it to better understand the impact of changes sure beats outage windows.
Strategies for modernization
Now that we’ve addressed moving faster and minimizing risk through data governance and testing, what about predictable cost models? Going back to our technical debt example, by fully separating the data from the infrastructure and focusing on managing the data itself, not the devices, we’ve unlocked your ability to consume technology as fast as you can field it.
This means models like hardware-as-a-service or subscription become financially beneficial. The best part, you own the data, so you are no longer locked into any single technology. There may be some details missing above since we have limited space, so I invite you to reach out to me personally to discuss. Until then, I encourage you to check out our latest in-depth newsletter titled Charting a New Course: Transforming Government Networks for the Digital Era. It features Gartner® research and also covers key issues and strategies that can help your agency tackle technical debt to modernize your mission networks, explores the Hype Cycle™ for Infrastructure Strategy, and how to modernize infrastructure platforms and operating models in support of digital foundations.
Additional resources
Notes:
Gartner, Hype Cycle for Infrastructure Strategy, 2023, Philip Dawson, Nathan Hill, 25 July 2023.
Gartner, Modernizing Infrastructure Platforms and Operating Models in Support of Digital Foundations, Dennis Smith, 7 June 2023.
GARTNER is a registered trademark and service mark of Gartner and Hype Cycle is a registered trademark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved.
Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of marchantability or fitness for a particular purpose.
Share: